Introduction
A Software Bill of Materials (SBOM) is a structured inventory of software components used within an application. It enhances transparency, security, and compliance while enabling organizations to track dependencies and mitigate risks. Creating an SBOM involves gathering details about all hardware, software, libraries, services, and dependencies present in a system. This document walks through the key components and the steps to collect relevant information.
Part 1
The first to list for SBOM is the application execution environment and supporting services needed for the software to successfully run. In this part we detail this section of the SBOM collection. This provides essential insights into a system's hardware and software configuration, which is useful for software deployment, troubleshooting, and Security auditing.
1.System Details – Basic System Information
- ●Operating System – Name, version, and architecture (e.g., Windows 11, Ubuntu 22.04, macOS)
- ●Host Name – Unique identifier for the machine
- ●Kernel Version – Helps in tracking vulnerabilities in OS components
- ●System Manufacturer & Model – For hardware reference and support
2.Hardware Inventory – CPU, RAM, Storage, Network
This section documents all physical hardware components:
- ●Processor (CPU) – Model, speed, core count (e.g., Intel i7-12700, 3.6GHz, 12 cores)
- ●Memory (RAM) – Total installed RAM and available memory (e.g., 16GB DDR4)
- ●Network Interfaces – MAC address, IP configurations, connected devices
- ●Docker Images: Base images, containerized applications, and running instances
- ●Virtual Machines: Details of VMs, snapshots, and hypervisor settings.
Purpose: Helps in capacity planning, performance monitoring, and hardware-specific security considerations.
3.Software Inventory – Installed Applications & Libraries
An SBOM should list all installed software, including:
- ●Operating System Packages – Pre-installed system components
- ●hird-Party Applications – Installed software like browsers, editors, security tools
- ●Programming Languages & Frameworks – Python, Java, Node.js, .NET
- ●Development Tools – Compilers, build tools, and SDKs
Purpose: Helps track software versions, identify outdated components, and ensure compliance.
4. Dependencies – Linked Libraries & Package Dependencies
Dependencies refer to external software components required for applications to run:
- ●System Libraries – Standard libraries linked to applications (e.g., libc, OpenSSL)
- ●Package Manager Dependencies – Python (pip), JavaScript (npm), Ruby (gem), etc
- ●Third-Party Modules – Open-source libraries, proprietary SDKs
Purpose: Helps in vulnerability scanning and licensing compliance by tracking all dependencies.
Part 2
1.Build Information – Compilation & CI/CD Details
- ●Build Logs: Logs from compilation, build tools, or CI/CD pipelines (e.g., Jenkins, GitHub Actions).
- ●Compilation Details: Compiler versions, build flags, and linked dependencies.
- ●Container Details: List of base images, runtime configurations, and Kubernetes manifests.
Purpose: Helps trace software origins, detect build-time vulnerabilities, and prevent supply chain attacks.
2.Kernel Modules & Drivers
- ●Loaded kernel modules (lsmod, Get-Module)
- ●Device drivers and firmware dependencies
3.Running Services – Active Processes & Network Services
Captures all active and background services:
- ●System Services – Web servers (Apache, Nginx), databases (MySQL, PostgreSQL), security tools (firewall, antivirus)
- ●Running Processes – All currently executing applications and system processes (ps –ef)
- ●Network Services & Open Ports – Helps detect unauthorized or insecure services
- ●Scheduled Tasks- (Cron Jobs, Windows Task Scheduler)
- ●Background Processes & Daemons: System background tasks and services.
Purpose: Identifies potential attack vectors and ensures only necessary services are running.
4.Security Findings – Identified Vulnerabilities (CVEs)
Captures all active and background services:
- ●Common Vulnerabilities and Exposures (CVEs) – Publicly known security flaws
- ●Security Updates & Patch Status – Status of installed patches for critical vulnerabilities
- ●User Privilege & Access Controls: Checks for unauthorized administrative access.
- ●Encryption Libraries: Ensures only secure libraries like OpenSSL or BouncyCastle are used.
- ●Certificates & Keys: Prevents expired certificates or insecure implementations.
- ●Authentication Mechanisms: SSH keys, digital signatures.
- ●Misconfigurations & Compliance Issues – Weak passwords, open ports, insecure dependencies
Purpose: Enhances security posture by identifying and mitigating risks in software and dependencies.
Part 3
Generate SBOM with tools:
Trivy
(SBOM + Vulnerability Scanning) Trivy a tool that automatically identifies the components within an application, an open source SBOM tool that supports both the SPDX and CycloneDX formats for generating SBOM.
- trivy fs --format cyclonedx --scanners vuln / > sbom.json
- For container images: trivy image --format cyclonedx -o sbom.json nginx:latest && trivy sbom sbom.json Create SBOM Format CycloneDX and Scans OS packages, application dependencies, misconfigurations, vulnerabilities for container
Syft & Grype (Anchore Tools) syft / -o spdx-json | grype sbom
Create SBOM Formats: SPDX, CycloneDX and scans: Software dependencies, OS packages
Dependency-Track (OWASP)
Generate SBOM & scan via APIUpload SBOM to Dependency-Track for automatic scanning
CycloneDX CLI (SBOM + Vulnerability Scan)
cyclonedx-cli analyze --input-file sbom.json
Create SBOM Formats: CycloneDX Scans: Dependencies, known vulnerabilities